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The starting point of this paper is a system described in form of a UML class diagram where system 
states are characterized by OCL invariants and system transitions are defined by OCL pre- and post- 
conditions. The aim of our approach is to assist the developer in learning about the consequences 
of the described system states and transitions and about the formal implications of the properties 
that are explicitly given. We propose to draw conclusions about the stated constraints by translat- 
ing the UML and OCL model into the algebraic specification language and system Maude, which is 
based on rewrite logic. We will concentrate in this paper on employing Maude's capabilities for state 
search. Maude's state search offers the possibility to describe a start configuration of the system and 
then explore all configurations reachable by rewriting. The search can be adjusted by formulating 
requirements for the allowed states and the allowed transitions. 



1 Introduction 



In the last years, model-driven development has become the topic of various research activities. The 
employment of models in all phases of software development and for different purposes is said to offer 
a higher level of abstraction than traditional code-centric development. Models should concentrate on 
crucial properties of a system to be developed or to be documented. Therefore, particular attention must 
be paid to checking such properties in order to guarantee software quality. For example, one is interested 
in verifying whether the formulated model properties are consistent, i.e., there are no contradictions 
between the properties, or one wants to check whether some further property is implied by other fixed 
properties. This paper will basically use UML and OCL to formulate models and properties in form 
of OCL constraints. OCL offers to express properties regarding the system states by invariants and 
properties concerning system transitions by pre- and postconditions. Thus static and dynamic aspects 
can be handled. 

Given a UML and OCL model of a system employing invariants and pre- and postconditions as the central 
description means, the developer frequently wants to know about the consequences on the described 
system states and transitions and about the formal implications of the properties that are explicitly given. 
For example, given some invariant and some state, one wants to check whether another state, where a 
further invariant does hold, can be reached by valid transitions or not. Concerning operation pre- and 
postconditions, the developer could wish to see all valid operation calls in a given state which satisfy the 
preconditions. Another question is whether from a given start state another explicitly given end state can 
be reached by valid operations such that all intermediate states are respecting the invariants. Questions 
like these and further ones will be handled in our approach. For example, in our approach it is also 
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82 Tracing OCL with Maude 

possible to ask for all sequences of messages and for all objects which have to be created in order to 
reach a state satisfying specific OCL constraints. 

On the technical level, we want to draw conclusions about the stated constraints by translating the UML 
and OCL model into the algebraic specification language and system Maude. Maude is based on rewrite 
logic, is a well-established language, and offers sophisticated tools for the analysis of specifications ||4]|. 
For example, Maude allows the developer to check the satisfiability of LTL formulas using its model 
checker, or to prove system properties with the inductive theorem prover ITP. However, we will concen- 
trate in this paper on employing Maude's capabilities for reachability analysis: we assume invariants are 
represented by state predicates, operations by Maude rules and pre- and postconditions by predicates as 
well. Basically, Maude's state search functionality offers the possibility to describe a start configuration 
of the system and then explore all configurations reachable from it by rewriting (or a finite subset of all 
reachable configurations by imposing a maximal depth on the graph of all possible configurations). The 
search can be adjusted by formulating requirements for the allowed states and the allowed transitions. To 
represent UML model in Maude and to evaluate OCL expressions on such models we use mOdCL lITTI . 

We assume the reader is familar with the Maude representation of classes, objects and configurations as, 
for example, described in (4]. We nevertheless provide a short description of the required Maude features 
in Section |3] The rest of this paper is structured as follows. In Section [2] we introduce our running 
example. Section [3] discusses the mOdCL representation of OCL types, user-defined UML classes, and 
OCL constraints. Section |4] concentrates on system dynamics by introducing the general approach to 
handle operation calls. Section [5] shows how to exploit properties of the model by employing the Maude 
state search. Section [6] finishes with concluding remarks and a brief discussion of future work. 



2 Running Example 

Our running example describes a simple marriage world in which persons can get married and can get 
divorced. In UML terms, we have a class Person and two enumerations Gender (with literals female, 

male) and CivilStatus (with literals single, married, divorced). In the Person class we have 
attributes civstat, gender, wife and husband. 

class Person 
attributes 

civstat : CivilStatus gender : Gender 

wife: Set (Person) husband: Set (Person) 
end 

For the example, we have decided to present the spouses with set-valued attributes, because we want 
to show how to use OCL expressions to avoid situations like polygamy and homosexual marriage, and 
because we wanted to avoid attributes being undefined. If we would have single-valued attributes, e.g., 
wife: Person, then an unmarried male would be represented with wife being equal to undefined, 
whereas in our model this is represented as wife being equal to the empty set. In the Person class there 
are two operations for marrying and divorcing explained in more detail below. We have developed and 
checked our example with the UML and OCL tool USE [6|. See Figure [T] 

As shown in the following, the states of the model are restricted by a number of OCL invariants and the 
transitions in the model, the operation calls, are required to obey certain operation contracts in form of 
OCL pre- and postconditions. 
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Figure 1: Snapshot of the USE tool for one of the example scenarios. 



A person should not be married to a person of the same gender (femaleHasNoWife and maleHas- 
NoHusband), a person can have at most one spouse (atMostOneHusband and atMostOneWif e), and 
marriage is a symmetric association (wifeHusbandinverse). We can express these invariants for the 
Person class in OCL: 

inv femaleHasNoWife: gender=f emale implies wife— >isEmpty () 
inv maleHasNoHusband: gencler=male implies husband— >isEmpty() 
inv atMostOneHusband: husband— >size ()<=1 
inv atMostOneWif e : wife— >size ()<=! 
inv wifeHusbandinverse: 

(wif e— >notEmpty ( ) implies wife . husband— >includes (self ) ) and 

(husband— >notEmpty () implies husband. wif e—>includes (self ) ) 



In order to guarantee consistency of the attribute values, one could additionally state the invariant 

(civstat=married) = (wife->notEmpty () or husband->notEmpty ( ) ) . 

Class Person has a marry (aSpouse : Person) operation. If (a) the argument aSpouse of the oper- 
ation is definedQ(b) both the person receiving the message and the argument aSpouse in the message 
are not maiTied, and (c) both persons have different gender, then the operation results in a state where 
both persons are married. The operation can be characterized as follows in OCLJj 

pre aSpouseDef ined: aSpouse . isDefined 



'in OCL, there is an exception element representing undefined; it is possible to pass this undefined element as an argument 
to a marry call. 

^Given the first part of the consequent husband=Set{aSpouse} in the f emaleHasMarriedHusband con- 
straint, one could simplify its second part to aSpouse . civstat =married assuming that the formal operation param- 
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pre isUnmarried : civstat'O-married 

pre aSpouseUnmarried: aSpouse . civstatOmarried 

pre dif f erentGenders : genderOaSpouse . gender 

post isMarried: civstat=married 

post f emaleHasMarriedHusband : gender =female implies 

husband=Set{aSpouse} and husband. civstat— >f orAll ( cs | cs=married) 
post maleHasMarriedWif e : gender=male implies 

wife=Set{aSpouse} and wif e . civstat— >f or All (cs | cs=married) 

Two married persons can get divorced using the divorce ( ) operation. This operation can be specified 
in OCL as follows: 

pre isMarried: civstat=married 

post isDivorced: civstat=divorced 

post husbandDivorced: gender=f emale implies 

husband— >isEmpty() and husband@pre . civstat— >f or All (cs | cs=divorced) 
post wif eDivorced : gender=male implies 

wif e— >isEmpty () and wif e@pre . civstat— >f or All (cs | cs=divorced) 



3 The mOdCL Representation of Class Diagrams 

The representation of UML models used in mOdCL is described in detail in flT] . This representation is 
inspired by the representation of object-oriented modules in Maude, as those used in Maude-based meta- 
modeling frameworks such as MOMENT |[T1, Maudeling Ifl2l . and e-Motions ifTOl . In these approaches, 
class diagrams are represented as Maude object-oriented modules, and system states as configurations of 
objects. The representation used in mOdCL has its own particularities, mainly in the representation of 
attributes, links and methods, and of course in the support of OCL. In comparison to other Maude-like 
approach to UML and OCL EllSl, mOdCL is the only Maude implementation providing support for pre- 
and postconditions, and the only one supporting the dynamic validation of OCL constraints. 

We briefly describe in the following sections the representation of class diagrams and OCL constraints 
used in mOdCL illustrating it with our running example. 

3.1 Object-Oriented Programming in Maude 

Maude |3i [4] is a high-level language and a high-performance system that supports membership equa- 
tional logic and rewriting logic specification and programming of systems. 

Membership equational logic fSl , a Horn logic whose atomic sentences are equalities t = t' and mem- 
bership assertions of the form t : S, stating that a term t has sort S. Such a logic extends order-sorted 
equational logic, and supports sorts, subsort relations, subsort polymorphic overloading of operators, and 
the definition of partial functions with equationally defined domains. 

Rewriting logic Q is a logic of change that can naturally deal with state and with highly nondeterministic 
concurrent computations. In rewriting logic, the state space of a distributed system is specified as an 
algebraic data type in terms of an equational specification (r,^), where Z is a signature of sorts (types) 
and operations, and £ is a set of equational axioms. The dynamics of a system in rewriting logic is 
then specified by rewrite rules of the form t — ;■ t', where t and t' are £-terms. This rewriting happens 



eter aSpouse cannot be changed by the operation. And similarly for the maleHasMarr iedWi f e constraint. However, 
we prefer in our example the explicit formulation. 
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modulo the equations E, describing in fact local transitions [f]^ — ;■ [t']E- These rules describe the local, 
concurrent transitions possible in the system, i.e. when a part of the system state fits the pattern t (modulo 
the equations E) then it can change to a new local state fitting pattern t'. 

In Maude, concurrent object-oriented systems can be naturally modeled in Maude as multisets of objects 
and messages, loosely coupled by some suitable communication mechanism. The basic sorts needed to 
describe an object system are: Object, Msg (messages), and Configuration. 

Given a class C with attributes aiiSi, ... , aniS,,, where a, are attribute identifiers and 5, are the sorts of 
the corresponding attributes, objects of such a class C are then record-like structures of sort Object of 
the form < O : C | ai : vi , ... , a,, : v„ >, where O is the (unique) identifier of the object, and v,- are the 
current values of its attributes. 

Objects can interact in a number of different ways, including message passing. Messages are declared in 
Maude as operations of sort Msg. 

To represent objects, additional sorts are available: Oid (object identifiers), Cid (class identifiers). 
Attribute (named elements of objects' states), and AttributeSet (comma-separated multisets of 
attributes). Thus, for example, for a class Account with a single attribute balance of sort Int, and 
messages withdraw and transfer we have the following declarations: 



sort Account 
















sul 


bsort Account 


< 


Cid 










op 


Account : - 


-> 


Accoun 


t [ctor] . 






op 


balance :_ 




Int -> 


Attribute 


[ct 


or] . 


op 


withdraw : 


0: 


Ld 


Int 


-> Msg 


[ctor] 




op 


transfer : 


0: 


Ld 


Oid 


Int -> 


Msg 


[ct 


or] . 



Thus, given the predefined operator 

op <_:_|^> : Oid Cid AttributeSet -> Object [ctor] . ~^' 

we can represent an account object with identifier a with balance 5 as a term 

< a : Account | balance : 5 > 

and a message to a to withdraw 3 as 

withdraw(a, 3) 

In a concurrent object-oriented system, the concurrent state, which is called a configuration, has the 
structure of a multiset made up of objects and messages that evolves by concurrent rewriting using 
rules that describe the effects of the communication events of objects and messages. The predefined 
sort Configuration represents configurations of Maude objects and messages, with none as empty 
configuration and the empty syntax operator as union of configurations. 

sort Configuration . 

subsorts Object Message < Configuration . 

op none : — > Configuration [ctor] . 

op : Configuration Configuration — > Configuration 

[ctor assoc comm id: none] . 

Thus, such rewrite rules define transitions between configurations, and their general form is: 

crl [r] : 

< Oi : Ci I attsi > ... < On : C„ \ atts,, > 



86 Tracing OCL with Maude 



Ml ... M„, 










=> < Oi, : c;, 


1 atts'.^ > . 


.. < Oi, 


■■ c[^ 


1 atts\^ > 


< Gi : c; 


1 atts'l > .. 


■ < Qp ■■ 


c'l 1 


atts'p > 


M[ ... m; 










if Cond . 











where r is the rule label, Mi...M,„ and M[...M' are messages, Oi...O„ and Qi-.-Qp are object identifiers, 
C\...Cn, C'l ...C- and C'(...C", are classes, /1...4 is a subset of l...n, and Cond is a Boolean condition (the 
rule's guard). The result of applying such a rule is that: (a) messages Mi...M„, disappear, i.e., they are 
consumed; (b) the state, and possibly the classes of objects Oi^...Oii^ may change; (c) all the other objects 
Oj vanish; {d) new objects Q\...Qp are created; and {e) new messages M[...M' are created, i.e., they are 
sent. Rule labels and guards are optional. When several objects or messages appear in the left-hand side 
of a rule, they need to synchronize in order for such a rule to be fired. 

Class inheritance is directly supported by Maude's order-sorted type structure. A subclass declaration c 
< C , indicating that c is a subclass of C , is a particular case of a subsort declaration c < C, by which 
all attributes, messages, and rules of the superclasses, as well as the newly defined attributes, messages 
and rules of the subclass characterize its structure and behavior. Multiple inheritance is also supported 
in Maude |l4|. 

3.2 OCL Basic Types 

Basic predefined OCL types are directly mapped on predefined Maude sorts. Thus, the OCL types 

Boolean, Integer, Real and String are mapped into the Maude predefined sorts Bool, Int, Float, 
and string, respectively. User-defined classes are mapped on the Maude predefined sort Old (of ob- 
ject identifiers). OCL predefined collection types are mapped into sorts Set, Bag, OrderedSet, and 
Sequence. All these sorts are subsorts of OclType. 

In OCL, the Enum sort is intended to be used to define enumeration types. Thus, types Gender and 
Civiistatus are declared as enumerations by declaring them as subsorts of Enum. The values of the 
types are then declared as constants of the respective types. E.g., the declarations for Civiistatus are: 

sort Civiistatus . 

subsort Civiistatus < Enum . 

ops single married divorced : — > Civiistatus [ctor] . 

Classes are represented following the standard representation of classes in Maude (see Section[3]and pi]). 
The Attribute sort provides the syntax for attributes and role ends in the objects, given by its name, 
of sort AttributeName, and its type, of sort OclType. 

op _:_ : AttributeName OclType -> Attribute [ctor] . 

The name of a given class C is represented as a constant C of the Maude sort Cid, and its attributes 
and role ends as constants of the mOdCL sort AttributeName. Thus, for the Person class we add 
declarations: 

sort Person . 

subsort Person < Cid . 

op Person : — > Person [ctor] 

ops civstat gender husband wife : — > AttributeName [ctor] . 

Role ends with multiplicity 1 are represented as attributes of sort Old, and role ends with multiplicity * 
as attributes of sort Set (for Old sets). 
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An operation op ( argi : typej , . . . , arg„ : type„ ) : type is represented as a constant op, of sort OpName 
(of operation names), and constants argi, ..., arg,„ of sort Arg (of arguments). Thus, operations 
marry (aSpouse : Person) and divorce ( ) require the following declarations: 

ops marry divorce : — > OpName [ctor] . 
op aSpouse : — > Arg [ctor] . 

Once we have defined the structural part, we can create object configurations. Since we will be using 
these configurations in several commands in the following sections, we define constants abc-single 
and ab-married-c-single representing, respectively, the object configurations in which persons ada, 
bob, and cyd are single, and ada and bob married and cyd single, respectively. 



ops ada bob cyd : — > Oid . 
















ops abc— single ab— married— c— single : 


— > Configuration . 










eq abc— single 
















= < ada : Person | gender 


female , 


civstat 


single , 


wife 


Set{}, 


husband 


Set{} > 


< bob : Person | gender 


male , 


civstat 


single , 


wife 


Set{}, 


husband 


Set{} > 


< cyd : Person | gender 


male , 


civstat 


single , 


wife 


Set{}, 


husband 


Set{} > . 


eq ab— married— c— single 
















= < ada : Person | gender 


female , 


civstat 


married , 


wife 


Set{}, 


husband : 


Set{bob} > 


< bob : Person | gender 


male , 


civstat 


married, 


wife 


Setjada} 


husband 


Set{} > 


< cyd : Person | gender 


male , 


civstat 


single , 


wife 


Set{}, 


husband 


Set{} > . 



3.3 OCL Constraints Representation 

In mOdCL, OCL expressions are represented as terms of sort OclExp. We can represent the OCL expres- 
sions from Section[2]as corresponding mOdCL terms of sort OclExp. The mOdCL terms mirror quite 
closely the OCL expressions given in Section [2] We give here a few of them for illustration purposes: 

op femaleHasNoWife : — > OCL— Exp . 

eq femaleHasNoWife = (context Person inv gender = female implies wife — > isEmptyO) . 

op atMostOneHusband : — > OCL— Exp . 

eq atMostOneHusband = (context Person inv husband — > size() <= 1) . 



op 


wif eHusbandl 


nverse : — > OCL— Exp . 
















eq 


wif eHusbandl 


nverse 


















= context 


Person inv 


















(wife 


-> 


notEmptyO implies wife 


. husban 


d -> 


incl 


udes 


(se 


If)) 


and 




(husband 


— > notEmptyO implies 


husband . 


wife 


-> 


incl 


ude 


s(se 


If)) . 



Op aSpouseDef ined : — > OCL— Exp . 

eq aSpouseDef ined = (aSpouse . isDefinedO ) 



op f emaleHasMarriedHusband : — > OCL— Exp . 










eq femaleHasMarriedHusband 










= (gender = female implies 










husband = SetjaSpouse} and husband 


civstat 


-> forAll(cs 


OS = 


= married) ) . 



op husbandDivorced : — > OCL— Exp . 










eq husbandDivorced 










= gender = female implies 










(husband — > isEmptyO and husband @pre 


civstat 


-> forAll(cs 


OS : 


= divorced)) . 



Notice the use of constants (like femaleHasNoWife) to identify these expressions. Invariants and pre- 
and postconditions are then specified by operators inv, pre and post in order to build the OclExp to 
be checked when the validation process requires to inspect invariants, pre- or postconditions of a given 
method, respectively. 
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op inv : — > OclExp . 

ops pre post : OpName — > OclExp . 

The global invariant to be satisfied is given as an operator inv defined as the conjunction of all invariant 
expressions. Given the above definitions, the inv constant can be defined as: 

eq inv = f emaleHasNoWif e and maleHasNoHusband and atMostOneHusband and 
atMostOneWif e and wif eHusbandlnverse . 

The pre and post operators must be defined for each method. These operators need the associated 
operation as an argument. We only show the corresponding declarations for the marry operation; it 
works analogously for divorce. 

eq pre(marry) = (aSpouseDef ined and isUnmarried and aSpouseUnmarried and dif ferentGenders) . 
eq post(marry) = (isMarried and f emaleHasMarriedHusband and maleHasMarriedWife) . 

With this structural description of the system, we can evaluate any OCL expression on object config- 
urations by using the mOdCL's eval operator. We can for instance evaluate the inv OCL expression 
defined above on the abc-single object configuration introduced in Section[3] 

Maude> red eval(inv, abc— single) . 
result Bool: true 



4 System Dynamics 

4.1 Representation of Operation Calls 

Once the static part of the system is completely determined, we can specify its behavior. We could do 
that in different ways, but our goal is to be able to generate execution traces leading to states satisfying 
or violating given OCL constraints. However, making sure that all invariants and pre- and postconditions 
are satisfied in the right places, is not an easy task. To discharge the user of the burden, mOdCL provides 
facilities to perform the appropriate checks in the appropriate places just by following very simple rules. 
Basically, the preconditions of an operation must be checked before its execution starts, and when it is 
completed, its postconditions and the invariants must be satisfied. To be able to automatically perform 
the checks before and after the execution of each operation, mOdCL expects that methods are invoked 
with a call message of the form 

call(<method— name>, <addressee>, <argument— list>) 

and upon their completion they send a return message of the form 

return(<return— value>) 

The infrastructure of mOdCL will intercept these messages and will take the following measures. 

The processing of a call operator results in the execution of a method, for which a context object, 
representing the execution context with the appropriate information for the running method, is generated. 
This object, of class Context, is of the form 

< Ctx : Context | op : M, self : Id, args : Vars > 

where ctx is the identifier of the object, M is the name of the active method, id is the identifier of the 
current object, and Vars is a set of (variable name,value) pairs corresponding to the arguments of the 
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method invocation and local variables. The modeler can make use of this Context object to get or 
manipulate the value of an argument variable or a local variable. 

A return message return (<return-value>) will be replaced by a resume message of the form 

resume(<return— value>) 

To manage the chaining of method invocations — an invoked method can invoke another one (or re- 
cursively itself) — the validator uses an execution stack in which the necessary information is storedjj 
mOdCL configurations are terms of sort Conf iguration+, which is declared as a sort with a single 
constructor 

op {_} : Configuration — > Conf iguration+ . 

where one of the objects in the wrapped configuration represents the execution stack, which is represented 
by a stack operator. 



4.2 Operations marry and divorce 



With these restrictions, we can specify the behavior of our operations as follows. Since the husband and 
wife attributes are sets of object identifiers, the marry operation just adds a new husband or a new wife 
to the corresponding set, depending on the gender of the receiver of the message. 



vars Ctx Self Dude : Oid 
vars Gdl Gd2 : Gender . 



vars Stl St2 : CivilStatus 
vars Hbl Hb2 Wfl Wf2 : Set 



rl [MARRY] : 












< Ctx : Context 


1 op : marry, self : Self, args : arg(aSpouse, Dude 


> 






marry— token 












< Self : Person 


1 civstat 


: Stl, gender : Gdl, husband : Hbl, wife 


Wfl > 
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1 civstat 
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Wf2 > 






=> if Gdl == female 
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civstat 


married, gender 


Gdl, husband 


SetJDude} , 


wife : Wfl 
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civstat 
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Gd2 , husband 


Hb2, wife 


: Set{Self} 
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else < Self 


Person | 


civstat 


married, gender 


Gdl , husband 


Hbl, wife 


: Set{Dude} 
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< Dude 
fi 
< Ctx : Conte 


Person | 


civstat 


married, gender 


Gd2 , husband 


SetjSelf }, 


wife : Wf2 


> 


3xt 1 op : 


marry, self : Self, args : arg(aSpouse, Di 


ide) > 






return(O) . 













In the case of the divorce operation, the set of the corresponding husbanci or wife attribute is just 
left empty. We use two rules to distinguish cases, depending on the gender, but show only the rule for 
females. 



vars Ctx Self Dude : Oid 
vars Gdl Gd2 : Gender . 



vars Stl St2 : CivilStatus . 
vars Attsl Atts2 : AttributeSet 



var Wf 



Set 



rl [DIVORCE] : 

< Ctx : Context | op : divorce, self : Self, args : empty > 
divorce— token 

< Self : Person | civstat : Stl, gender : female, husband : SetJDude}, Attsl > 

< Dude : Person j civstat : St2 , wife : Wf , Atts2 > 

=> < Self : Person | civstat : divorced, gender : female, husband : Set{}. Attsl > 

< Dude : Person | civstat : divorced, wife : Set{}, Atts2 > 

< Ctx : Context | op : divorce, self : Self, args : empty > 
return(O) . 



^mOdCL currently assumes a single thread of execution. A multithreaded execution would also be possible just by adding 
support for multiple stacks. 
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These methods are very simple, and they are both specified so that their execution will consists in the 
application of one rule. The marry-token and divorce-token operators are used to prevent the 
execution of the rules corresponding to the operation out of the scope of a call to such an operation. 
More intricate methods may require several rules to be executed sequentially, in which case more than a 
simple token will be required. 

Methods are invoked with call operators. However, for convenience, and to use a notation more 
friendly, we will use the following operators. 

op _. marry(_) : Oid Oid — > Msg [msg] . 
op _. divorce : Oid — > Msg [msg] . 

These methods will be used to produce the sending of a corresponding call message. 

rl [MARRY-INVOCATION] : 
Self . marry(Arg) 
stack{nil) 
=> call (marry. Self, 

stack(nil) 

marry— token . 



arg(aSpouse, Arg)) 



rl [DIVORCE-INVOCATION] : 
Self . divorce () 
stack(nil) 
=> call(divorce , Self, empty) 

stack(nil) 

divorce— token . 

Notice the presence of the stack operator, with nil contents in both rules, to guarantee that no new 
message is sent until the execution stack is empty, that is, the processing of all previous messages has 
been completed. 

Given this behavior we can simulate the system by using the rewrite Maude commandjjor we can 
explore all possible executions searching for states satisfying a specific property. 



]VIaiide> rew { abc— single 












cyd . marry (ada) 












stack(nil) } . 












result Conf iguration + : 












{ stack(nil) 












resume (marry , 0) 












< ada : Person | civstat 


married 


gender 


: female, husband : Setjcyd}, 


wife : Set{} 


> 


< bob : Person | civstat 


single , 


gender : 


male, husband : Set{}, wife 


Set{} > 




< cyd : Person | civstat 


married 


gender 


: male, husband : Set{}, wife 


: Setjada} > 


} 



What happens if we try to do something that does not respect the defined constraints? For instance, if 
we send a marry message to an already mamed person, the precondition of the marry operation should 
fail. mOdCL will detect situations like this and will send corresponding error messages. 

]VIaude> rew { ab— married— c— single 

cyd . marry(ada) 

stack(nil) } . 
result [Conf iguration + ] : 
{ marry— token 



< ada 


Person | civstat : married 


gender 


< bob 


Person | civstat : married 


gender 


< cyd 


Person | civstat : single. 


gender 


error ( 


Precondition^violation" , 







: female, husband : Setjbob}, 
: male, husband : Set{}, wife 
male, husband : Set{}, wife ; 



wife : Set{} > 
: Setjada} > 
Set{} > 



^The rewrite IVIaude command (abbreviated rew) causes the specified term to be rewritten using the rules, equations, 
and membership axioms in the given module. 
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marry , 




aSpouse . 


isDefined-O and civstat O married and 


gender O 


aSpouse . gender and aSpouse . civstat O married) } 



The error message provides a string explaining the failure, and the OCL expression that has failed. In the 
case of pre- and postconditions, the name of the operation of the condition is also indicated. 



5 Tracing Properties 



Notice that the configuration rewritten is a set, and so, if several messages were in it, no order in which 
they are to be consumed is assumed. If we were interested in a sequence of messages with a specific order, 
we could very easily specify it. But this associative-commutative configuration allows us to explore 
the different traces in which certain messages may be consumed. For instance, the following search 
command looks up all possible traces leading to states in which there are two persons married using 
messages cyd . marry (ada) , ada . marry (bob) , and bob . divorce (). 



Maiide> search { abc— single 






(cyd . marry(ada)) 




(ada . marry(bob)) 




(bob . divorce ()) 




stack(nil) } 






=>* { stack(nil) 






Conf : Configuration } 




such that 






eval(Person . alllnstances — > exists(P | 




Person . alllnstances — > exists(Q | 




P . wife 


-> includes(Q) and Q . husband -> includes(P) ) ) , 




Conf : Conf iguration) . 




Solution 1 (state 4) 






Conf : Configuration 






— > bob . divorce () 






resume(marry , 0) 






(cyd . marry (ada)) 






< ada : Person | civstat 


married, gender : female, husband : Setjbob}, wife : Set{} 


> 


< bob : Person | civstat 


married, gender : male, husband : Set{}, wife : Setjada} > 




< cyd : Person | civstat 


single, gender : male, husband : Set{}, wife : Set{} > 




Solution 2 (state 5) 






Conf : Configuration 






— > bob . divorce 






resume(marry , 0) 






(ada . marry(bob)) 






< ada : Person | civstat 


married, gender : female, husband : Setjcyd}, wife : Set{} 


> 


< bob : Person | civstat 


single, gender : male, husband : Set{}, wife : Set{} > 




< cyd : Person | civstat 


married, gender ; male, husband : Set{}, wife : Setjada} > 




Solution 3 (state 12) 






Conf : Configuration 






— > resume (marry , 0) 






resume (marry , 0) 






resume ( divorce , 0) 






< ada : Person | civstat 


married, gender : female, husband : Setjcyd}, wife : Set{} 


> 


< bob : Person | civstat 


divorced, gender : male, husband : Set{}, wife : Set{} > 




< cyd : Person | civstat 


married, gender : male, husband : Set{}, wife : Setjada} > 




No more solutions . 







The Maude search command gives us all possible reachable states satisfying the specified OCL expres- 
sion. More interestingly, we have access to the paths followed for each of these solutions. By using the 
show path and show path labels commands, we can get all the information on the path followed 
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up to any of the states in the search space, and specifically to the ones given as solutions of the search 
command — notice the state number given on the right of the solution number. 

Maude> show path labels 12 . 

MARRY-INVOCATION 

MARRY 

DIVORCE-INVOCATION 

DIVORCE 

MARRY-INVOCATION 

MARRY 



5.1 Spontaneous Generation of Messages 

This is very powerful already, but we can do more. In the above search we had to give what messages 
we wanted to use to generate all possible paths. But that does not guarantee that we get all possible ways 
to get a specific state. We now present a possible alternative in which new messages are spontaneously 
generated. As a result of the execution we are interested in getting the sequence of messages leading to 
the searched states. To obtain it, we add a messages operator that keeps the list of messages generated. 



sort MsgList . 








subsort Msg < MsgList . 








op nilMsgList : — > MsgList . 








op _;_ : MsgList MsgList — > MsgList 


[assoc 


id: 


nilMsgList] . 


op messages : MsgList — > Msg [ctor] 









Consider the following rules, by which, if there exist two persons, a new marry message for the marriage 
of these two persons is generated: 



var ML : MsgList . 


vars Dudel Dude2 : Old . 


vars Attsl Atts2 : AttributeSet 


var Arg : OclType . 


rl [NEW-MARRY-MESSAGE] : 




< Dudel : Person | Attsl > 




< Dude2 : Person | Atts2 > 




messages(ML) 




=> < Dudel : Person | Attsl > 




< Dude2 : Person | Atts2 > 




hold(messages (ML ; Dudel . 


marry (Dude2 ) ) ) 


Dudel . marry (Dude2) . 





In addition to sending a new marry message, the rule adds the generated message to the list of messages. 
And, since we do not want to generate a new message until the previous one was consumed, we block 
the messages operator with a hold operator. 

op hold : Msg — > Msg [ctor] . 



Once the operation has finished. 


we can 


unblock the 


message 


list. 


var ML : MsgList . 


var 


Arg : 


OclType . 






rl [RETURN-MARRY] : 
resume(marry , Arg) 
hold (messages (ML) ) 
=> messages (ML) . 













Similar rules are added to spontaneously generate new divorce messages. 
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Notice the use of the messages operator to collect the sequence of messages generated. When a new 
message is generated it is added to the list of messages in the messages operator. With it we will know 
the messages used to reach a given state. We could instead use the show path command to get the 
sequence of rules, and from it obtain the sequence of messages, but notice that the search command 
looks for states, and only keeps the shortest path to each reached state. 

We can get, e.g., the states reached when searching for married couples. Of course, the number of 
reachable states satisfying this condition is infinite, and we must either limit the number of solutions to 
look for or the maximum depth of the search. We can search for the first 10,000 states as follows: 



Maude> search [10000] 








{ stack(nil) 








abc— single 








messages 


nilMsgList ) 


} 






=>* { Conf 


Configuration messages (ML : MsgList ) } 






such that 










eval(Person . alllnstances — > exists(P | 








Person . alllnstances — > exi3t3(Q | 








P . wife - 


-> includes(Q) and Q . husband — > includes (P) ) ) 






Conf : Conf iguration) . 






Solution 1 (state 17) 








Conf : Configuration 










— > stack(nil) 










< ada : Person | civstat 


married, gender : female, husband : Setjbob}, 


wife : Set{} 


> 


< bob : Person | civstat 


married, gender : male, husband : Set{}, wife 


: Setjada} > 




< cyd : Person | civstat 


single, gender : male, husband : Set{}, wife 


Set{} > 




ML:MsgList — > ada 


marry (bob) 








Solution 10000 (state 131696) 








Conf : Configuration 










— > stack(nil) 










< ada : Person | civstat 


married, gender : female, husband : Setjcyd}, 


wife : Set{} 


> 


< bob : Person | civstat 


divorced, gender : male, husband : Set{}, wife : Set{} > 




< cyd : Person | civstat 


married, gender : male, husband : Set{}, wife 


: Setjada} > 




ML:MsgList — > ada 


marry ( cyd) 








cyd 


divorce () 








bob 


marry (ada) 








bob 


divorce () 








cyd 


marry (ada) 








cyd 


divorce () 








ada 


marry ( cyd) 








ada 


divorce ( ) 








cyd 


marry (ada) 









We may also look for more interesting states. For example, we may search for states in which the 
precondition of an operation fails. We must again limit the search. 

Maude> search [20,20] 

{ stack(nil) 

abc— single 

messages (nilMsgList ) } 
=>* { error(Str: String, ON : OpName , Exp:OCL-Exp) 
Conf : [Configuration] 
hold(messages(ML :MsgList ) ) } . 
Solution 1 (state 10) 
Conf : [Configuration] 



— > marry— token 



ada 


Person 


1 civstat 


single , 


gender 


female, husband 


bob 


Person 


1 civstat 


single , 


gender 


male , husband : 


cyd 


Person 


1 civstat 


single , 


gender 


male , husband : 


ist — 


-> bob . 


marry ( cyd) 









: Set{mt}, wife 
Set{mt}, wife : 
Setjmt}, wife ; 



: Set{mt} > 
Set{mt} > 
Setjmt} > 
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Str: string — > "Precondition^violation" 

ON : OpName — > marry 

Exp:OCL-Exp 

— > aSpouse . isDefined() and civstat O married and 

gender O aSpouse . gender and aSpouse . civstat O married 

Solution 20 (state 74) 
Conf : [Configuration] 
— > marry— token 



married, gender : female, husband : Setjbob}, wife : Set{mt} > 
married, gender : male, husband : Set{mt}, wife : Set{ada} > 
single, gender : male, husband : Set{mt}, wife : Set{mt} > 



< ada : Person | civstat 

< bob : Person | civstat 

< cyd : Person | civstat 
ML:MsgList — > (bob . marry(ada)) ; cyd . marry(bob) 
Str: String — > "Precondition^violation" 

ON : OpName — > marry 

Exp : OCL— Exp — > aSpouse . isDefined() and civstat O married and 

gender O aSpouse . gender and aSpouse . civstat O married 

However, we can show how we cannot reach states in which invariants are not satisfied. 



Maude> 


search [20,20] 












{ stack(nil) 












abc— single 












messages (nilMsgList ) 


} 










=>* { error(Str : String 


Exp 


OCL- 


Exp) 






Conf : [Configurat 


Lon] 










ho Id (mess ages (ML 


MsgList)) 


} ■ 


No 


solution . 









Of course, since we have limited the search, the absence of solutions does not imply that such states do 
not exist. But notice that the reachable state space is infinite because of the messages operator. Without 
it, the state space is in fact small for our example. We can verify properties on our example by using an 
equational abstraction 1*91 consisting in just removing the messages in the messages list. 

var ML : MsgList . 

ceq messages(ML) = messages (nilMsgList ) if ML =/= nilMsgList . 

We can now, for example, prove that within our Maude description no reachable state fails the invariant. 




Or more interestingly, that after you many you will never be single again. 

Maude> search { stack (nil) 

ab— married— c— single 
messages(nilMsgList ) ] 
=>* { Conf : [Conf iguration] 

messages(ML) } 
such that 

eval(ada . civstat = single or bob . civstat = single, Conf) 
No solution. 
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5.2 Spontaneous Generation of Objects 

But why limiting ourselves to playing with ada, bob, and cyd? In the same way we can spontaneously 
generate new messages to consider all possible sequences of messages, we can also think on the possi- 
bility of spontaneously generating new objects. In fact, what we need is just a new or create message 
that gives place to the object. We declare a new message with the identifier of the object, its class, and 
its gender to generate Person objects. 

op new : Oid Cid Gender — > Msg [ctor] . 

As in the generation of messages, to generate a new object we need to initialize its attributes. In our 
current example, they are generated single, and the only values we need to worry about are their identifier 
and their gender. Genders can be assigned nondeterministically. We give two rules to generate objects of 
each of the possible genders. Regarding identifiers, we use a counter operator to both indexing object 
identifiers id{l), id{2), ... and limiting the number of generated objects. 

op id : Nat -> Oid [ctor] . 

op counter : Nat — > Msg [ctor] . 

var ML : MsgList . var N : Nat . var G : Gender . var : Oid . 

ops P Q : -> Vid . 

rl [NEW-MALE] ; 
counter (s N) 
messages (ML) 
=> counter(N) 

new(id(N), Person, male) 

hold(messages (ML ; new(id(N), Person, male))) . 

rl [NEW-FEMALE] : 

counter(s N) 

messages(ML) 

=> counter(N) 

new(id(N), Person, female) 

hold(messages (ML ; new(id(N), Person, female))) . 
rl [PERSON-GENERATION] : 
new(0. Person, G) 
hold (messages (ML) ) 
=> < : Person | civstat : single, gender : G, husband : Set{}, wife : Set{} > 

messages (ML) . 

We can now look for traces reaching states with married couples as follows: 



Maude> search [100,30] { stack(nil) 


messages (nilMsgList) 


counter (3) } 


=>* { Conf : Configuration messages (ML : MsgList ) } 


such that 


eval(Person . alllnstances — > exists(P | 


Person . alllnstances — > exists(Q | 


P . wife — > includes(Q) and Q . husband — > includes(P) ) ) , 


Conf) . 


Solution 1 (state 121) 


Conf : Configuration 
— > 
stack(nil ) 


counter ( 1 ) 


< id(l) : Person | civstat : married, gender : female, husband : Set{id(2)}, wife : Set{} > 


< id(2) : Person | civstat : married, gender : male, husband : Set{}, wife : Set{id(l)} > 


ML:MsgList — > new(id(2) , Person, male) ; 


new(id(l). Person, female) ; 
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id(l) . marry(id(2)) 








Solution 2 (state 122) 








Conf : Configuration 
— > 
stack(nil ) 














counter ( 1 ) 








< id(l) : Person | civstat : married, 


gender 


: female, husband : Set{id(2)}, wife : Set{} 


> 


< id(2) : Person | civstat : married, 


gender 


: male, husband : Set{}, wife : Set{id(l)} > 




MLiMsgList — > new(id(2) , Person, male) 


; 






new(id(l). Person, femal 


e) ; 






id(2) . marry(id(l)) 








Solution 100 (state 2420) 








Conf : Configuration 
— > 
stack(nil) 














counter (0) 








< id(l) : Person | civstat : married. 


gender 


: female, husband : Set{id(0)}, wife : Set{} 


> 


< id(2) : Person | civstat : single. 


gender : 


male, husband : Set{}, wife : Set{} > 




< id(0) : Person | civstat : married. 


gender 


: male, husband : Set{mt}, wife : Set{id(l)} 


> 


ML:MsgList — > new(id(2). Person, male) 


; 






new(id(l). Person, femal 


e) ; 






new(id(0) , Person, male) 


; 






id(l) . marry(id(0)) ; 








id(0) . divorceO ; 








id(0) . marry(id(l)) 









We can look for persons married to themselves. 



Maude> 


search 


[20, 


20] 


{ stack(nil) messages( 


nilMsgLis 


t) 


count 


er 


(3) 


} 












=> 


* { 


Conf : Configuration 
messages (ML iMsgList) } 






















such 


that 


eval(Person . alllnstances 


-> exists 


(P 1 
























P . wife — > includes 


(P) or P 


. hu 


sband 


> 


inclu 


des 


(p)). 












Conf : Conf iguration) . 


















No 


solution . 

























6 Conclusions 

We have made a proposal to draw consequences about stated constraints in a UML and OCL model 
by translating the model into Maude. Maude allows the developer to check for system properties in 
various ways. We have employed the Maude state search and were able to show that particular states 
can (resp. cannot) be reached under given assumptions, i.e., by limiting the search to a finite subset of 
possible configurations. We have generated scenarios, i.e., state sequences and transitions, where the 
transition sequences were automatically constructed in order to achieve a path from a start state to an end 
state. 

We believe Maude with its sophisticated tools offers more and even stronger possibilities than the one 
we have employed. The Maude ITP theorem prover could be used to achieve general propositions about 
invariants. The Maude temporal logic checker could be employed for verifying and finding complex 
states and transition constellations. Fine grained information about constraint failure would be desirable 
for mOdCL. Larger case studies must give feedback about the practicability of our approach. All results 
obtained on the Maude level must be translated back into UML and OCL, for example, in terms of object 
and sequence diagrams. 
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